Method and Apparatus for Storing Data in a Peer to Peer Network

ABSTRACT

A fixed prefix peer to peer network has a number of physical nodes. The nodes are logically divided into a number of storage slots. Blocks of data are erasure coded into original and redundant data fragments and the resultant fragments of data are stored in slots on separate physical nodes such that no physical node has more than one original and/or redundant fragment. The storage locations of all of the fragments are organized into a logical virtual node (e.g., a supernode). Thus, the supernode and the original block of data can be recovered even if some of the physical nodes are lost.

This application claims the benefit of U.S. Provisional Application No.60/890,661 filed Feb. 20, 2007 which is incorporated herein byreference.

BACKGROUND OF THE INVENTION

The present invention relates generally to peer to peer networking andmore particularly to storing data in peer to peer networks.

Peer to peer networks for storing data may be overlay networks thatallow data to be distributively stored in the network (e.g., at nodes).In peer to peer networks, there are links between any two peers (e.g.,nodes) that communicate with each other. That is, nodes in the peer topeer network may be considered as being connected by virtual or logicallinks, each of which corresponds to a path in the underlying network(e.g., a path of physical links). Such a structured peer to peer networkemploys a globally consistent protocol to ensure that any node canefficiently route a search to some peer that has desired data (e.g., afile, piece of data, packet, etc.). A common type of structured peer topeer network uses a distributed hash table (DHT) in which a variant ofconsistent hashing is used to assign ownership of each file or piece ofdata to a particular peer in a way analogous to a traditional hashtable's assignment of each key to a particular array slot.

However, traditional DHTs do not readily support data redundancy and maycompromise the integrity of data stored in systems using DHTs. Toovercome these obstacles in existing peer to peer networks, files orpieces of data are N-way replicated, but this results in high storageoverhead and often requires multiple hashing functions to locate copiesof the data. Further, it is difficult to add support for monitoring dataresiliency and automatic rebuilding of missing data.

Accordingly, improved systems and methods of organizing and storing datain peer to peer networks are required.

BRIEF SUMMARY OF THE INVENTION

The present invention generally provides a method of storing data in afixed prefix peer to peer network having a plurality of physical nodes.A plurality of data fragments are generated by erasure coding a block ofdata and each of the data fragments are then stored in differentphysical nodes. In one embodiment, the erasure coding divides the blockof data into a number of original fragments and a number of redundantfragments are created where the number of redundant fragments is equalto a predetermined network cardinality minus the number of original datafragments. The physical nodes in the peer to peer network are logicallydivided into storage slots and the data fragments are stored indifferent slots on different physical nodes. The storage locations ofthe fragments (e.g., the slots) are logically organized into a virtualnode.

To generate the data fragments by erasure coding, a network cardinalityis determined, the block of data is divided into a number of originalfragments, and a number of redundant fragments are created wherein thenumber of redundant fragments is equal to the network cardinality minusthe number of original data fragments.

The storage locations of the plurality of data fragments are mapped in adata structure in which the storage locations are the physical nodes inwhich the plurality of data fragments are stored. In some embodiments,the data structure is a distributed hash table.

These and other advantages of the invention will be apparent to those ofordinary skill in the art by reference to the following detaileddescription and the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of an exemplary peer to peer network according to anembodiment of the invention;

FIG. 2 is a diagram of an exemplary peer to peer network according to anembodiment of the invention;

FIG. 3 is a diagram of an exemplary peer to peer network according to anembodiment of the invention;

FIG. 4 is an exemplary supernode composition and component descriptiontable 400 according to an embodiment of the present invention;

FIG. 5 is a depiction of data to be stored in a peer to peer network;

FIG. 6 is a flowchart of a method of storing data in a fixed prefix peerto peer network according to an embodiment of the present invention; and

FIG. 7 is a schematic drawing of a controller according to an embodimentof the invention.

DETAILED DESCRIPTION

The present invention extends the concept of Distributed Hash Tables(DHTs) to create a more robust peer to peer network. The improvedmethods of storing data described herein allow for a simple DHTorganization with built-in support for multiple classes of dataredundancy which have a smaller storage overhead than previous DHTs.Embodiments of the invention also support automatic monitoring of dataresilience and automatic reconstruction of lost and/or damaged data.

The present invention provides greater robustness and resiliency to theDHT-based peer to peer network known as a Fixed Prefix Network (FPN)disclosed in U.S. patent application Ser. No. 10/813,504, filed Mar. 30,2004 and incorporated herein by reference. Unlike traditional peer topeer networks, FPNs and networks according to the present invention,known as FPNs with Supernodes (FPN/SN), are constructed such that thecontributed resources (e.g., nodes) are dedicated to the peer to peersystem and the systems are accordingly significantly more stable andscalable.

FIGS. 1-3 depict various illustrative embodiments of peer to peernetworks utilizing FPN/SNs. FIGS. 1-3 are exemplary diagrams toillustrate the various structures and relationships described below andare not meant to limit the invention to the specific network layoutsshown.

FIG. 1 is a diagram of an exemplary peer to peer network 100 for usewith an embodiment of the present invention. The peer to peer network100 has a plurality of physical nodes 102, 104, 106, and 108 thatcommunicate with each other through an underlying transport network 110as is known. There is no restriction on the location, grouping, ornumber of the physical nodes 102-108 with regards to the presentinvention. Though depicted in FIG. 1 as four physical nodes 102-108, itis understood that any number of nodes in any arrangement may beutilized. Similarly, the physical nodes 102-108 may vary in actualstorage space, processing power, and/or other resources.

Physical nodes 102-108 each have associated memories and/or storageareas (not shown) as is known. The memories and/or storage areas ofphysical nodes 102-108 are each logically divided into a plurality ofslots approximately proportional to the amount of storage available toeach physical node. That is, the memory and/or storage area of physicalnode 102 is logically divided into approximately equivalent-sized slots112 a, 112 b, 112 c, and 112 d, the memory and/or storage area ofphysical node 104 is logically divided into approximatelyequivalent-sized slots 114 a, 114 b, 114 c, and 114 d, the memory and/orstorage area of physical node 106 is logically divided intoapproximately equivalent-sized slots 116 a, 116 b, 116 c, and 116 d, andthe memory and/or storage area of physical node 108 is logically dividedinto approximately equivalent-sized (e.g., in terms of storage capacity)slots 118 a, 118 b, 118 c, and 118 d. A physical node may be logicallydivided in that its memory and/or storage allocation may be allocated asdifferent storage areas (e.g., slots). Physical nodes 102-108 may bedivided into any appropriate number of slots, the slots beingrepresentative of an amount of storage space in the node. In otherwords, data may be stored in the nodes 102-108 in a sectorized orotherwise compartmentalized manner. Of course, any appropriate divisionof the storage and/or memory of physical nodes 102-108 may be used andslots 112 a-d, 114 a-d, 116 a-d, and 118 a-d may be of unequal size.Further, slot size may not be static and may grow or shrink and slotsmay be split and/or may be merged with other slots.

Each physical node 102-108 is responsible for the storage and retrievalof one or more objects (e.g., files, data, pieces of data, datafragments, etc.) in the slots 112 a-d, 114 a-d, 116 a-d, and 118 a-d,respectively. Each object may be associated with a preferably fixed-sizehash key of a hash function. In operation, one or more clients 120 maycommunicate with one or more of physical nodes 102-108 and issue arequest for a particular object using a hash key.

Slots 112 a-d, 114 a-d, 116 a-d, and 118 a-d may also each be associatedwith a component of a virtual (e.g., logical) node (discussed in furtherdetail below with respect to FIGS. 2 and 3). Herein, components are notphysical entities, but representations of a portion of a virtual node.That is, components may be logical representations of and/or directionsto or addresses for a set or subset of data that is hosted in aparticular location in a node (e.g., hosted in a slot). Storagelocations of data fragments (e.g., data fragments discussed below withrespect to FIG. 5) are logically organized into a virtual node.

FIG. 2 is a diagram of a portion of an exemplary peer to peer network200 for use with an embodiment of the present invention. The peer topeer network 200 is similar to peer to peer network 100 and has aplurality of physical nodes 202, 204, 206, 208, 210, and 212 similar tophysical nodes 102-108. Physical nodes 202-212 are each logicallydivided into a plurality of slots approximately proportional to theamount of storage available to each physical node. That is, physicalnode 202 is divided logically into slots 214 a, 214 b, 214 c, and 214 d,physical node 204 is divided logically into slots 216 a, 216 b, 216 c,and 216 d, physical node 206 is divided logically into slots 218 a, 218b, 218 c, and 218 d, physical node 208 is divided logically into slots220 a, 220 b, 220 c, and 220 d, physical node 210 is divided logicallyinto slots 222 a, 222 b, 222 c, and 222 d, and physical node 212 isdivided logically into slots 224 a, 224 b, 224 c, and 224 d. Forsimplicity of discussion and depiction in FIG. 2, since each slot 214a-d, 216 a-d, 218 a-d, 220 a-d, 222 a-d, and 224 a-d hosts a component,the component corresponding to its host slot is referred to herein withthe same reference numeral. For example, the component hosted in slot214 c of physical node 202 is referred to as component 214 c.

A grouping of multiple components is referred to as a virtual node(e.g., a “supernode”). In the example of FIG. 2, supernode 226 comprisescomponents 214 b, 216 c, 218 b, 220 d, 222 a, and 224 a. A virtual node(e.g., supernode) is thus a logical grouping of a plurality of storagelocations on multiple physical nodes. The supernode may have any numberof components—where the number of components is the supernodecardinality (e.g., the number of components in a supernode)—associatedwith any number of physical nodes in a network and a supernode need nothave components from every physical node. However, each component of asupernode must be hosted in slots on different physical nodes. That is,no two components in a supernode should be hosted at the same physicalnode. The total number of components in a supernode may be given by apredetermined constant—supernode cardinality. In some embodiments, thesupernode cardinality may be in the range of 4-6 32. The supernodecardinality may be a predetermined (e.g., desired, designed, etc.)number of data fragments.

In some embodiments, a larger supernode cardinality is chosen toincrease flexibility in choosing data classes. In alternativeembodiments, a smaller supernode cardinality is chosen to providegreater access to storage locations (e.g., disks) in read/writeoperations. Here, data classes define a level of redundancy where lowerdata classes (e.g., data class low) have less redundancy and higher dataclasses (e.g., data class high) have more redundancy. There may be anumber of data classes equal to the predetermined supernode cardinality.The lowest data class is defined as having no redundant fragment and thehighest class is defined as having (supernode cardinality—1) redundantfragments.

In an exemplary embodiment, data class low may refer to a singleredundant fragment and data class high may refer to four redundantfragments. Of course, any appropriate number of data fragments may beset for data class low and/or data class high. In this exemplaryembodiment, data blocks that are classified by user as data class lowwill be divided into a number of fragments equal to a supernodecardinality, where there are (supernode cardinality—1) originalfragments and one redundant fragment. Accordingly, one fragment may belost and the data block may be recreated. Using data class high (e.g.,four redundant fragments) a block of data will be divided into fragmentssuch that four of them will be redundant. Thus, four fragments may belost and the original block of data may be recreated. Fragmentation,especially redundant fragments, is discussed in further detail belowwith respect to FIG. 5.

Components of the supernode may be considered peers and may similarlyassociated (e.g., in a hash table, etc.), addressed, and/or contacted aspeer nodes in a traditional peer to peer network.

FIG. 3 depicts a high level abstraction of an exemplary peer to peernetwork 300 according to an embodiment of the invention. Peer to peernetwork 300 is similar to peer to peer networks 100 and 200 and hasmultiple physical nodes 302, 304, 306, and 308. Each of the physicalnodes 302-308 is divided into multiple slots as described above. In theparticular example of FIG. 3, each of the physical nodes 302-308 haseight slots. As in FIG. 2, each slot 310, 312, 314, 316, 318, 320, 322,or 324 hosts a component 310, 312, 314, 316, 318, 320, 322, or 324.Components 310-324 are each associated with a corresponding supernodeand are distributed among the physical nodes 302-308. In this way, eightsupernodes are formed, each with one component 310-324 on each of thefour physical nodes 302-308. For example, a first supernode is formedwith four components—component 310 hosted on physical node 302 (e.g., ina slot 310), component 310 hosted in physical node 304 (e.g., in a slot310), component 310 hosted in physical node 306 (e.g., in a slot 310),and component 310 hosted in physical node 308 (e.g., in a slot 310). Thefirst supernode, comprising components 310, is shown as dashed boxes. Asecond supernode comprises the four components 312 hosted in physicalnodes 302-308 and is shown as a trapezoid. Of course, these are merelygraphical representations to highlight the different componentscomprising different supernodes and are not meant to be literalrepresentations of what a slot, component, node, or supernode might looklike. The remaining six supernodes are formed similarly.

To facilitate data storage using the supernodes as described and shownin FIGS. 1-3, the fixed prefix network model of DHTs (e.g., FPN) may beextended to use supernodes. Any advantageous hashing function that mapsdata (e.g., objects, files, etc.) to a fixed-size hash key may beutilized in the context of the present invention. The hash keys may beunderstood to be fixed-size bit strings (e.g., 5 bits, 6 bits, etc.) inthe space containing all possible combinations of such strings. Asubspace of the hashkey space is associated with a group of bits of thelarger bit string as is known. For example, a group of hash keysbeginning with 110 in a 5 bit string would include all hash keys exceptthose beginning with 000, 001, 010, 011,100, and 101. That is, theprefix is 110. Such a subspace of the hashkey space may be a supernodeand a further specification may be a component of the supernode. Theprefix may be fixed for the life of a supernode and/or component. Insuch embodiments, the peer to peer network is referred to as afixed-prefix peer to peer network. Other methods of hashing may be usedas appropriate.

FIG. 4 is an exemplary supernode composition and component descriptiontable 400 according to an embodiment of the present invention. Thesupernode composition and component description table 400 may be used inconjunction with the peer to peer network 200, for example. Eachsupernode (e.g., supernode 226) is described by a supernode composition(e.g., with supernode composition and component description table 400)comprising the supernode prefix 402, an array 404 of the componentdescriptions, and a supernode version 406. Since each component has adescription as described below, the array 402 size is equal to thesupernode cardinality. The supernode version 406 is a sequence numbercorresponding to the current incarnation of the supernode. Eachsupernode is identified by a fixed prefix 402 as described above and inU.S. patent application Ser. No. 10/813,504. For example, in hashingand/or storing data in peer to peer network 200 according to supernodecomposition and component description table 400 in which hash keys arefixed size bit strings, the supernode 226 has a fixed prefix of 01101.Therefore, any data that has a hash key beginning with 01101 will beassociated with supernode 226.

In operation, each component (e.g., 214 b, 216 c, 218 b, 220 d, 222 a,224 a, etc.) in the component array 404 is described by a componentdescription comprising a fixed prefix 408, a component index 410, and acomponent version 412. All components of the supernode (e.g., in array404) are also assigned the same fixed prefix for their lifetime. Thecomponent index 410 of each component corresponds to a location in thesupernode array. A component's index is fixed for the component'slifetime and is an identification number pointing to the particularcomponent. A component index is a number between 0 and (supernodecardinality—1). A component's version is a version number sequentiallyincreased whenever the component changes hosts (e.g., nodes). In someembodiments, described in detail in concurrently filed U.S. patentapplication Ser. No. ______, entitled “Methods for Operating a FixedPrefix Peer to Peer Network”, Attorney Docket No. 06083A, incorporatedby reference herein, a component may be split or moved from one physicalnode to another and its version is increased in such instances.

Supernode composition and component description table 400 is an exampleof an organization of the information related to physical nodes,supernodes, and their respective components. Of course, one skilled inthe art would recognize other methods of organizing and providing suchinformation, such as storing the information locally on physical nodesin a database, storing the information at a remote location in acommunal database, etc.

Updated indications of the supernode composition are maintained (e.g.,in supernode composition and component description table 400, etc.) tofacilitate communication amongst peers. Further, physical nodesassociated with the components maintain compositions of neighboringphysical and/or virtual nodes. To maintain such compositions, physicalnodes associated with components ping peers and neighbors as is known.In this way, a physical node associated with a component may internallyping physical nodes associated with peers in the component's supernodeto determine virtual node health and/or current composition. Further, aphysical node associated with a component may externally ping physicalnodes associated with neighbors (e.g., components with the same index,but belonging to a different supernode) to propagate and/or collectcomposition information. Of course, other systems and methods oforganizing and/or keeping track of supernodes and their components,including version/incarnation information may be used as appropriate.

FIG. 5 is a generalized drawing of data that may be stored in peer topeer networks 100, 200, and/or 300. A block 502 of data may be dividedinto multiple pieces 504 of data according to any conventional manner.In at least one embodiment, the block of data 502 may be fragmented intomultiple original pieces (e.g., fragments) 506 and a number of redundantfragments 508 may also be generated. Such fragmentation and/or fragmentgeneration may be accomplished by erasure coding, replication, and/orother fragmentation means.

FIG. 6 depicts a flowchart of a method 600 of organizing data in a fixedprefix peer to peer network according to an embodiment of the presentinvention with particular reference to FIGS. 2 and 5 above. Thoughdiscussed with reference to the peer to peer network 200 of FIG. 2, themethod steps described herein also may be used in peer to peer networks100 and 300, as appropriate. The method begins at step 602.

In step 604, a network cardinality is determined. Network cardinalitymay be a predetermined constant for an entire system and may bedetermined in any appropriate fashion.

In step 606, a plurality of data fragments 506-508 are generated. In atleast one embodiment, the data fragments 506-508 are generated from ablock of data 502 by utilizing an erasure code. Using the erasure codetransforms a block 502 of n (here, four) original pieces of data 504into more than n fragments of data 506-508 (here, four originalfragments and two redundant fragments) such that the original block 502of n pieces (e.g., fragments) of data 504 can be recovered from a subsetof those fragments (e.g., fragments 506-508). The fraction of thefragments 506-508 required to recover the original n pieces of data 504is called the rate r. In some embodiments, optimal erasure codes may beused. An optimal erasure code produces n/r fragments of data where any nfragments may be used to recover the original n pieces of data. Inalternative embodiments, near optimal erasure codes may be used toconserve system resources. In the same or alternative embodiments, theblock of data 502 is divided into n pieces 506. Based on the original npieces 506, m redundant fragments 508 are created where (m=supernodecardinality−n) and the fragment size is equal to the size of theoriginal block of data 502 divided by n. It may be understood that theerasure coding and creation of redundant fragments 508 allows recreationof the original block of data 502 with half plus one redundant fragments508 and/or original fragments 506. In the example shown in FIG. 5, onlyfour total fragments from the group of fragments 506-508 are needed toreconstruct original block of data 502. Of course, any other erasurecoding scheme may be used.

In step 608, the data fragments 506-508 are stored in different physicalnodes 202-212. Each of the data fragments 506, representing the originalpieces of the data block 502, and the redundant fragments 508 are storedin separate physical nodes 202-212 using any appropriate methods ofstoring data in a peer to peer network. In at least one embodiment, datafragments 506-508 are stored in separate slots 214 a-d, 216 a-d, 218a-d, 220 a-d, 222 a-d, 224 a-d of the physical nodes 202-212. Forexample, one fragment from fragments 508 and 508 may be stored in eachof slots 214 b, 216 c, 218 b, 220 d, 222 a, and 224 a.

A hash may be computed based on the original block of data 502. Avirtual node (e.g., virtual node 226) is then found that has the samefixed prefix as the prefix of the computed hash. Since, virtual node 226comprises components 214 b, 216 c, 218 b, 220 d, 222 a, and 224 a, thedata fragments 506-508 are then stored in the slots 214 b, 216 c, 218 b,220 d, 222 a, and 224 a corresponding to components 214 b, 216 c, 218 b,220 d, 222 a, and 224 a.

In step 610, the storage locations of the data fragments 506-508 arerecorded (e.g., mapped, etc.) in a data structure. The data structuremay be a hash table, a DHT, a DHT according to the FPN referenced above,the data structures described in co-pending and concurrently filed U.S.patent application Ser. No. ______, entitled “Methods for Operating aFixed Prefix Peer to Peer Network”, Attorney Docket No. 06083A,incorporated by reference herein, or any other appropriate datastructure. The data structure may facilitate organization, routing,look-ups, and other functions of peer to peer networks 100, 200, and300. Fragments 506-508 may be numbered (e.g., from 0 to a supernodecardinality minus one) and fragments of the same number may be stored(e.g., grouped, arranged, etc.) in a logical entity (e.g., a virtualnode component).

In step 612, the data structure facilitates organization of informationabout the data fragments 506-508 into virtual nodes (e.g., supernode226, supernodes 310-324, etc.). That is, the storage locations (e.g.,the slots in the physical nodes) storing each of the original fragments506 and each of the redundant fragments 408 are organized into and/orrecorded as a grouping (e.g., a virtual node/supernode as describedabove). Accordingly, the fragments 506-508 may be organized into andhosted in supernode 226 as described above so that location, index, andversion information about the fragments of data 506-508 may be organizedas components of supernode 226.

The method ends at step 614.

FIG. 7 is a schematic drawing of a controller 700 according to anembodiment of the invention. Controller 700 contains a processor 702that controls the overall operation of the controller 700 by executingcomputer program instructions that define such operation. The computerprogram instructions may be stored in a storage device 704 (e.g.,magnetic disk, database, etc.) and loaded into memory 706 when executionof the computer program instructions is desired. Thus, applications forperforming the herein-described method steps, such as erasure coding,storing data, and DHT organization, in method 600 are defined by thecomputer program instructions stored in the memory 706 and/or storage704 and controlled by the processor 702 executing the computer programinstructions. The controller 700 may also include one or more networkinterfaces 608 for communicating with other devices via a network (e.g.,a peer to peer network, etc.). The controller 700 also includesinput/output devices 710 (e.g., display, keyboard, mouse, speakers,buttons, etc.) that enable user interaction with the controller 700.Controller 700 and/or processor 702 may include one or more centralprocessing units, read only memory (ROM) devices and/or random accessmemory (RAM) devices. One skilled in the art will recognize that animplementation of an actual controller could contain other components aswell, and that the controller of FIG. 7 is a high level representationof some of the components of such a controller for illustrativepurposes.

According to some embodiments of the present invention, instructions ofa program (e.g., controller software) may be read into memory 706, suchas from a ROM device to a RAM device or from a LAN adapter to a RAMdevice. Execution of sequences of the instructions in the program maycause the controller 700 to perform one or more of the method stepsdescribed herein, such as those described above with respect to method600 and/or erasure coding as described above with respect to FIG. 5. Inalternative embodiments, hard-wired circuitry or integrated circuits maybe used in place of, or in combination with, software instructions forimplementation of the processes of the present invention. Thus,embodiments of the present invention are not limited to any specificcombination of hardware, firmware, and/or software. The memory 706 maystore the software for the controller 700, which may be adapted toexecute the software program and thereby operate in accordance with thepresent invention and particularly in accordance with the methodsdescribed in detail below. However, it would be understood by one ofordinary skill in the art that the invention as described herein couldbe implemented in many different ways using a wide range of programmingtechniques as well as general purpose hardware sub-systems or dedicatedcontrollers.

Such programs may be stored in a compressed, uncompiled and/or encryptedformat. The programs furthermore may include program elements that maybe generally useful, such as an operating system, a database managementsystem, and device drivers for allowing the controller to interface withcomputer peripheral devices, and other equipment/components. Appropriategeneral purpose program elements are known to those skilled in the art,and need not be described in detail herein.

The inventive methods of organizing a peer to peer network describedherein improve network resiliency. Since each supernode includes thefragments derived from an original block of data (e.g., by erasurecoding) and each of the fragments is thus stored on a separate physicalnode, the network is less susceptible to failure due to network changes.That is, changes to the peer physical nodes such as failures and nodedepartures are less likely to affect the peer to peer network because ofthe distributed nature of the data.

Accordingly, the inventive methods may be employed on a peer to peernetwork. A controller (e.g., controller 700) may perform hashingfunctions store and/or look up one or more pieces of data in the peer topeer network. The controller may further be configured to recover thestored data should one or more of the physical nodes be lost (e.g.,through failure, inability to communicate, etc.) Of course, the physicalnodes in the peer to peer network may be configured to perform one ormore of the functions of the controller instead.

The foregoing Detailed Description is to be understood as being in everyrespect illustrative and exemplary, but not restrictive, and the scopeof the invention disclosed herein is not to be determined from theDetailed Description, but rather from the claims as interpretedaccording to the full breadth permitted by the patent laws. It is to beunderstood that the embodiments shown and described herein are onlyillustrative of the principles of the present invention and that variousmodifications may be implemented by those skilled in the art withoutdeparting from the scope and spirit of the invention. Those skilled inthe art could implement various other feature combinations withoutdeparting from the scope and spirit of the invention.

1. A method of storing data in a fixed prefix peer to peer network having a plurality of physical nodes comprising: generating a plurality of data fragments by erasure coding a block of data; storing each of the plurality of data fragments in different physical nodes.
 2. The method of claim 1 wherein storing each of the plurality of data fragments in different physical nodes comprises: logically dividing each of the physical nodes into a plurality of slots; and storing each of the plurality of data fragments in different slots on different physical nodes.
 3. The method of claim 3 further comprising: associating the different slots on different physical nodes as a virtual node.
 4. The method of claim 1 wherein generating a plurality of data fragments by erasure coding a block of data comprises: determining a network cardinality; dividing the block of data into a number of original fragments; and creating a plurality of redundant fragments wherein the number of redundant fragments is equal to the network cardinality minus the number of original data fragments.
 5. The method of claim 1 further comprising mapping storage locations of the plurality of data fragments in a data structure wherein the storage locations are the physical nodes in which the plurality of data fragments are stored.
 6. The method of claim 5 wherein the data structure is a distributed hash table.
 7. A peer to peer network for storing fragments of data comprising: a plurality of physical nodes each logically divided into a plurality of slots; a plurality of controllers associated with each of the physical nodes and configured to associate the plurality of physical nodes as one or more logical nodes comprising a grouping of slots wherein each of the one or more logical nodes includes slots from more than one of the physical nodes.
 8. The peer to peer network of claim 7 wherein the controllers are further configured to store a plurality of data fragments in the grouping of slots.
 9. The peer to peer network of claim 8 wherein the controllers are further configured to map storage locations of the plurality of data fragments in a data structure wherein the storage locations are the physical nodes in which the plurality of data fragments are stored.
 10. A machine readable medium having program instructions stored thereon, the instructions capable of execution by a processor and defining the steps of: generating a plurality of data fragments by erasure coding a block of data; storing each of the plurality of data fragments in different physical nodes.
 11. The machine readable medium of claim 10 wherein the instructions further define the steps of: logically dividing each of the physical nodes into a plurality of slots; and storing each of the plurality of data fragments in different slots on different physical nodes.
 12. The machine readable medium of claim 10 wherein the instructions further define the step of: associating the different slots on different physical nodes as a virtual node.
 13. The machine readable medium of claim 10 wherein the instructions further define the step of: mapping storage locations of the plurality of data fragments in a data structure wherein the storage locations are the physical nodes in which the plurality of data fragments are stored.
 14. The machine readable medium of claim 13 wherein the instructions further define the step of: mapping the storage locations of the plurality of data fragments in a distributed hash table.
 15. An apparatus for storing data in a fixed prefix peer to peer network having a plurality of physical nodes comprising: means for generating a plurality of data fragments by erasure coding a block of data; means for storing each of the plurality of data fragments in different physical nodes.
 16. The apparatus of claim 15 wherein the means for storing each of the plurality of data fragments in different physical nodes comprises: means for logically dividing each of the physical nodes into a plurality of slots; and means for storing each of the plurality of data fragments in different slots on different physical nodes.
 17. The apparatus of claim 16 further comprising: means for associating the different slots on different physical nodes as a virtual node.
 18. The apparatus of claim 15 further comprising: means for mapping storage locations of the plurality of data fragments in a data structure wherein the storage locations are the physical nodes in which the plurality of data fragments are stored. 